home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 5 / QRZ Ham Radio Callsign Database - Volume 5.iso / files / amiga / cdoc720j.lzh / cbbs-multi.doc < prev    next >
Encoding:
Text File  |  1993-08-25  |  7.0 KB  |  187 lines

  1.  
  2.       C-BBS V7.20j (Multi-Port) for the AMIGA (Kickstart V1.3 and V2.0)
  3.                       Multi-Port Documentation (DRAFT)
  4.                        Copyright VE5VA 13th April 1993
  5.  
  6.  
  7.  BEFORE  you  try  to run multiple ports make a BACKUP of EVERYTHING. I will
  8.  not  be held responsible for the loss of any data. Use this version at your
  9.  own risk! 
  10.  
  11.  
  12.       I have  finally  solved  the  problem  of  mediating  between multiple
  13.  processes  all  trying  to  read or write the mail.dat, user.dat and bid.mb
  14.  files.  I  have  added  code that uses semaphores to control access to each
  15.  file.   When  running  multiple copies of 'mb' you still only need ONE copy
  16.  of the following files: 
  17.  
  18.     mail.dat
  19.     user.dat
  20.     config.mb
  21.     bid.mb
  22.     help.mb
  23.     info.mb
  24.     states.mb
  25.     reject.btn
  26.  
  27.  
  28.       Other files  require  a  separate  copy for each port, but in order to
  29.  allow  a single-port system to be run without any changes, the names of the
  30.  files  for  port  A  do  not change from what is specified in the config.mb
  31.  file.   For  example, the log.mb file is still called log.mb on port A, but
  32.  on  all  other  ports the system changes the name so that the suffix is the
  33.  port  letter.  Therefore,  the  'mb'  that  runs  on port D will create and
  34.  maintain  a  log  file called log.d. Most of the files such as the log file
  35.  and  calls.mb  are created by the system with correct names if they are not
  36.  present  when  the program starts.  There are only a few that the user must
  37.  create.   All  the  following  files  require  multiple  copies and will be
  38.  created in the same way as shown in the table below.  
  39.  
  40.  Port ->     A         B           C          .......
  41.  
  42.           log.mb     log.b       log.c          etc.
  43.           mon.mb     mon.b       mon.c
  44.           calls.mb   calls.b     calls.c
  45.           tnc.on     tnc.on.b    tnc.on.c
  46.           tnc.off    tnc.off.b   tnc.off.c
  47.           talk.on    talk.on.b   talk.on.c
  48.           talk.off   talk.off.b  talk.off.c
  49.  
  50.  
  51.       The first  three  in the list are created automatically by the system.
  52.  The  remaining  files  must  be created by the user if the files are needed
  53.  (e.g.   you  probably  won't  have  talk.on  or  talk.off files for all the
  54.  ports).  
  55.  
  56.  
  57.       The bulletin.a,  bulletin.b  etc.  files are unchanged and are created
  58.  as needed by the sysop.  
  59.  
  60.  
  61.       When you  start  up each copy of 'mb' it must have the -pP argument on
  62.  
  63.  
  64.  it  to specify which port (P) the program is to use. If it is not specified
  65.  then  the  port letter P defaults to port A (see the example startup script
  66.  below).  
  67.  
  68.  
  69.       The config.mb  file does not change and all ports are specified in the
  70.  one  copy  of  config.mb. You tell a specific copy of 'mb' which port it is
  71.  to  use  by specifying the port letter as an argument when 'mb' is started.
  72.  It  then  reads only that port and port 'Z' from the port description list.
  73.  To  simplify  the  startup  procedure, I have modified the code so that you
  74.  can  specify  the device unit number and name, in that order, at the end of
  75.  the  port specification line. The unit number defaults to zero and the name
  76.  defaults  to  "serial.device". You can still use the -u and -n arguments if
  77.  you  wish. The content of the config.mb file will override the arguments if
  78.  they  are  both  given.  Here is an example of the beginning of a config.mb
  79.  file describing two ports: 
  80.  
  81.  A123UDRT 600 20 600 100 20 4  5 8 15      0 serial.device
  82.  -> 145.01 Mhz.
  83.  B123UDRT 600 20 600 100 20 4 15 8 15      1 serial.device
  84.  -> 443.71 Mhz
  85.  ZCE#D  300 10 600 100 10 0 27 8  0
  86.  -> Stations Connected
  87.  *** EOF
  88.  
  89.  Note  that in V7.2, the console port is now port Z (not port L).  When each
  90.  copy  starts  up,  it  creates a public port which contains the name of the
  91.  port  so  that  you  can  start  up your system in an orderly fashion.  For
  92.  example,  port B will create the port name "CBBS-B" and your startup script
  93.  can  use  waitport  to  wait until this name is created before it starts up
  94.  the next port. E.g.  
  95.  
  96.  ; This script is used with the multi-port version of 'mb'.
  97.  ; An example of starting up a 3 port system. I have omitted details like
  98.  ; specifying the window position and size using the -w argument.
  99.  ; This example assumes that the port unit and device names are specified
  100.  ; in config.mb
  101.  ;
  102.  ; Always delete T:mbuser.index at startup if it exists.
  103.  if exists T:mbuser.index
  104.  delete T:mbuser.index
  105.  endif
  106.  ;
  107.  ; Change to the directory containing C-BBS
  108.  ;
  109.  cd work:cbbs
  110.  ;
  111.  ; Start locker
  112.  run locker
  113.  waitport VE5VA-LOCK 20
  114.  ;
  115.  ; I don't need the -z argument when running mb because it is set with the
  116.  ; setenv command in my s:startup-sequence.
  117.  ; Default to port A on startup
  118.  ;
  119.  run mb
  120.  waitport CBBS-A 20
  121.  ; Specify port B
  122.  run mb -pB
  123.  waitport CBBS-B 20
  124.  
  125.  
  126.  ; and port C
  127.  run mb -pC
  128.  waitport CBBS-C 20
  129.  ; and just as an example lets get sysop going too
  130.  run sysop
  131.  waitport CBBS-1 20
  132.  
  133.  
  134.       Note that   at   the   beginning,   the  script  looks  for  the  file
  135.  T:mbuser.index  and if it exists it is deleted. In order to handle multiple
  136.  accesses  to  the  user file, I had to change the way in which it checks to
  137.  see  if it knows a specific user callsign. In the original C-BBS, each copy
  138.  of  'mb'  kept  its own list of callsigns in a table. This causes a problem
  139.  because  if  the  user  file  changes size then every process must recreate
  140.  their  internal  table.  To simplify things, I changed the code so that the
  141.  table  is  stored  in  the  file  T:mbuser.index which is accessible to all
  142.  processes.  The  first  process to start up (usually port A, but it doesn't
  143.  have  to  be)  will find that the index is not in ram so it will get a lock
  144.  on  the  user  file,  create the index and then release the lock. The other
  145.  processes  will  find  that  the  index  is  already there and won't try to
  146.  recreate  it.  The  file is only modified if a user is added to, or deleted
  147.  from,  the user.dat file.  In this case, the process making the change will
  148.  also  change the index. The other processes will find out that the file has
  149.  changed  when  they try to access the lock on the file and this causes them
  150.  to  close  the  file  and  reopen it so that they see the changes that have
  151.  been  made.  This  is  essentially  how  the  locking  is  handled with the
  152.  mail.dat  too  except that it doesn't need an index file - it is the index.
  153.  The only other file that required locking was the bid.mb file.  
  154.  
  155.  
  156.       The forwarding  process has been modified slightly to prevent multiple
  157.  copies  of  'mb' trying to do a forward on the console port 'Z' at the same
  158.  time.   Only  the  port  A  process  will do forwarding for the console and
  159.  therefore  there MUST be a port A process if you want forwarding for port Z
  160.  to be done.  
  161.  
  162.  
  163.       The locking  which  prevents  'GM',  'GU' and 'GR' from being executed
  164.  while  any other process is active is still incorporated in the program. If
  165.  you  set a forwarding script so that a 'GM' is done automatically at 3am it
  166.  will  only  succeed  if  nobody  else  is  logged  in  at the time AND THIS
  167.  INCLUDES THE SYSOP PROCESS which must be idle when the 'GM' is attempted.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.